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(57) ABSTRACT 

A secure token device, such as a smart card or an ibutton, 
provides a user with a vehicle for accessing services that are 
provided by an Internet Service Provider (ISP). The user 
places the secure token device in communication with a 
reader that is coupled to a computer system. The computer 
system includes a web browser for accessing the services 
provided by the ISP. The secure token device may perform 
an authentication protocol to authenticate itself to the ISP. 
The ISP may also be required to authenticate itself. The 
secure token device may hold an electronic currency token 
for payment of services rendered by the ISP. The secure 
token device may contain stored personal information about 
the user. The user may stipulate what portions of this 
personal information are provided to the ISP upon request. 
Contextual information regarding sessions with the ISP may 
also be stored on the secure token device and used to restore 
a context of a previous session during a subsequent session. 
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SECURE TOKEN DEVICE ACCESS TO 
SERVICES PROVIDED BY AN INTERNET 
SERVICE PROVIDER (ISP) 

TECHNICAL FIELD OF THE INVENTION 

The present iavention relates generally to data processing 
systems and more particularly to secure token device access 
to services provided by an Internet Service Provider (ISP). 

BACKGROUND OF THE INVENTION 

An ISP is a vendor who provides customers with access 
to the Internet. Examples of ISPs include America Online 
(AOL), CompuServe and the Microsoft Network (MSN). In 
addition to providing access to the Internet, ISPs may also 
provide additional services to their customers, inchiding 
chat rooms, news services, electronic mail messaging and 
bulletin board services. 

ISPs provide access to the Internet to customers by 
employing one or more Internet servers. These servers are 
directly connected to the Internet and act as conduits for 
customers to access web pages resident on other servers on 
the Internet. Typically, a customer uses a conventional 
modem to place a call to a designated ISP server The 
modem need not be a conventional modem but may be 
instead, a cable modem or a wireless modem. The ISP server 
answers the call and a connection is established between the 
server and the customer's computer. After this connection is 
established, the customer is prompted to login. In particular, 
the customer is prompted usually to enter a user ID and a 
password. The information entered by the customer is com- 
pared to data stored in a database with the ISP to determine 
whether the user is who the user purports to be. If the 
customer provides the proper information and has sufficient 
privileges, the customer is granted access to the Internet. 

There are a number of drawbacks associated with the 
above-described conventional approach to providing Inter- 
net access to customers. First, the Internet Protocol (IP) is 
used for messaging addressing on the Internet and the 
protocol is a connectionless protocol. As such, the protocol 
does not support the persistent storage of contextual infor- 
mation. Thus, any contextual information associated with 
one customer session on the Internet is not carried forward 
to the next customer session. Each session must start anew 
in creating a context Second, the conventional approach to 
providing access to the Internet by ISPs is susceptible to 
fraud. If a party can obtain a user ID and password for a user, 
the party can gain access to the Internet via the user's 
account. Third, most ISPs currently provide only one variety 
of service such that all customers are offered this single 
variety of service. For example, all customers may be 
offered full access to a complete range of services provided 
by an ISP and all customers may be charged a fiat fee for a 
designated time frame of service (e.g. for a month of service 
or a year of service). Customers who use the services more 
frequently than other customers are not charged additional 
amounts. Hence, there is a lack of flexibility in the pricing 
and senrice options available to customers from ISPs in 
conventional systems. 

SUMMARY OF THE INVENTION 

The present invention addresses the limitations of the 
prior art by providing users with secure token device access 
to services offered by ISPs. "Secure-token devices"are 
devices such as smart cards and ibuttons that hold currency 
tokens and other information in a secure fashion. Preferably, 
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the secure token device is of a size, shape and weight that it 
is easily carried by a user. The secure token device may even 
be wearable by a user. When a user wishes to access services 
provided by an ISP, the user puts a secure token device in 

5 communication with a reader. The reader is a device that is 
configured to read and communicate with the secure token 
device. The reader is coupled to a computer system, such as 
a personal digital assistant (PDA), workstation or a personal 
computer (PC). When the user places the secure token 
device in or against the reader (depending on the type of 
reader), the reader recognizes the insertion of the secure 
token device and prompts the computer system to begin 
communicating with the secure token device. The computer 
system may seek to verify that the user is the proper owner 

J J of the secure token device. To that end, the computer system 
may request that tbe user enter a personal identification 
number (PIN). The user enters a PIN and the PIN is 
compared with a PIN value that is stored on the secure token 
device. If the PIN value entered by the user matches the PIN 
value on the secure token device, the computer system 
verifies that the user is the owner of the secure token device 
and the process of accessing the ISP services may be 
initiated. 

Tbe secure token device may hold identification informa- 

25 tion that is globally unique across geographic and political 
boundaries. This identification information is held securely 
on the secure token device. It is dif&cult for a party to 
physically access the identification information. The secure 
token device serves as a physical token of authenticity for 

3Q the party. In order to fraudulently use the secure token 
device, a party must both physically take the secure token 
device and also be aware of the PIN associated with the user 
of the secure token device. Hence, the use of the secure 
token device helps to decrease the probability of fraud. 

35 Contextual information (i.e., a context) may be stored on 
the secure token device of the user Tbe context may, for 
example, identify user preferences and configuration infor- 
mation. When a user seeks to access the services of tbe ISP, 
the context fi^om a previous session may be restored by 

40 retrieving the context from the secure token device. This 
ability to preserve context enhances the services provided to 
the user and eliminates the need for tbe user to recreate a 
context each time the user accesses ISP services. 

The seciue token device may also support various elec- 

45 tronic banking or electronic commerce mechanisms that 
facilitate the exchange of electronic currency. The secure 
token device may be used in realizing payment for services 
provided by ISPs. The user may download currency tokens 
from the secure token device to the ISP to cover expenses 

50 associated with the services provided during a given session. 
This ability to receive payment for services during a session 
with the user enhances the abihty of ISPs to uilor pricing 
schemes on a per use basis. An ISP may charge a user for the 
services rendered during a given session as opposed to using 

55 a flat rate scheme over an extended time period, such as a 
month or a year. Thus, users are diarged on the basis of the 
resources they consume rather than on a flat rate basis. 

The secure token device of a user may contain personal 
information regarding a user, such as name, address, and 

60 credit card account information. Tbe user has the ability to 
customize what portions of this personal information may be 
accessed by a service provider. Hence, the user may deter- 
mine that an ISP should only be given access to the user's 
name and address and should not given access to the user's 

65 credit card account information. For another service 
provider, the user may grant the service provider fiill access 
to all of the personal information. This approach has the 
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added benefit of storing personal inforaQation more securely by eoiploying a secure token device, such as a smart card or 

than instances where the personal information is stored on an ibutton (such as produced by Dallas Semiconductor 

database maintained by an ISP. It should be noted, however. Corporation). The secure token device is a secure electronic 

that ISPs may store additional information on secure token device that holds globally unique identification information 

devices that is not readily accessible to users. A further 5 regarding the user. The user may be required to enter a 

benefit of this approach is that it gives the user control over password or PIN to verify that the user is the same party 

what personal information the user grants to respective ^1^,5^ identification information is stored on the secure 

parties. Still, further, the storage of personal information 00 ^^^^ ^^^^ secure token device is programmed to 

the secure token device faahtates wmpanies to develop ^ two-way verificaUon between the user and the ISP. 

toyalty marketmg programs, such as frequent flier programs. 3 jfi^^i the user must prove that the user is who the user 

T^c frequent flier indcs of a user may be stored on the secure J ^ ^ ^ ^ 

token device, added to the storage on the secure token device F'^F"; ^ " u ^ 

and redeemed from the secure token device, ^^'^ P^'P^^ ^ 

„^ „^,,^«,«^^*r .^„^r^r. ^h^ sccurc tofccu device may hold contextual information 

-BRIEF DESCRIPTION OF THE DRAWINGS behalf of the user. He contextual information may 

An illustrative embodiment consistent with the principles is capture the context of a previous session with the ISP When 

of the present invention will be described below relative to the user again gains access to the services of the ISP, the 

the following drawings. context from the previous session may be restored. For 

FIG. 1 is a block diagram that illustrates hardware com- example, user preferences and other contextual information 

ponents used to practice the illustrative embodiment of the that were entered in a previous session may be carried 

present invention. 20 forward into the new session. 

HGS. 2A and 2B illustrate the exemplary layout for a ^^j^^^ ^^^-^^ ^ ^^^^^ programs. TTie 

smart card to be used m the illustrative embodiment 01 the • 1 j j r r -i-.T * .u 

programs may mclude code for facmtatmg access to the 

present mvcntion. ^ ^. ^ j ^ r 1 • 

r-..r^-»^ii.. L L ^ ji crtr> services of an ISP and code for electronic commerce trans- 

FIG. 2C illustrates the contacts on the smart card 01 FIG. -m. . . -i .1. i_ c 

. _ . . actions. These iransacUons may entail the exchange of 

2A m more detail. 25 1 ^ ■ • .1. c * 1 ^ t. .i_ 

1 c i_ . u J electromc currency m the form of tokens. Thus, when the 

FIG. 3 illustrates an example of an ibutton nng to be used „ „ u .u • . 

... r*i- * • user accesses a web site or other service that requires 

m the illustrative embodiment of the present invention. . . j • r _i 

r-.^ ^ . t-i 1 J- -11 . ^* ^ payment DDr the tendering of goods or services, the user can 

FIG. 4 IS a block diagram illustratmg compuimg compo- r.u j . ^ ^ j 

tu^ r^i™ A^ri^ the goods or services using the tokens oontamed 

nents on tne secure token device. ' . . ^ . . 1 j • t l u l 

r» • LI 1 J- t. . • . r services based on the secure token devices. It should be 

FIG. 3 IS a block digram Jlustratmg components of the 30 j^^d that the ISPs may serve the role of distributor for 

computer system ot HO. 1 m more detail. distributing the secure token devices to customer. 

FIG. 6 illustrates the various Java packages that are found i.- .i.-r 

. 1 J • The secure token device may hold information regarding 

on the secure token device. . . . . n in. u . i 

„„ „ ^ .„ , . . , J L L the user that is potentially sensitive. The user has control 

FIG. 7A illustrates object classes that are supported by the ... r^,. • r ^- tl. t . i. * 

, i< overdissemmationofthismformation. The user selects what 

computer system of HG.l. 35 information are avaUablc to re^cctive 

HG. 7B illustrates object-glasses that are part of the requesters. Different requesters may be granted different 

CardTerminal component. permissions. For example, a first requester may receive a 

FIG. 7C illustrates object-classes that arc part of the first set of personal information and a second requester may 

CardAgent component. receive a second set of personal information that differs from 

FIG. 7D illustrates object-classes that are part of the the first set. 

CardIO component. The use of the sccurc token device enables ISPs to tailor 

FIG. 8A illustrates the logical format of a command their service offerings and billing options to individual users. 

^D^- The users may be offered different service options. For 

FIG. 8B illustrates the logical format of a response example, a first user may be offered a service option where 

APDU. the user is only permitted to browse the Internet. A second 

FIG. 9 is a flow chart that illustrates the steps that are user, in contrast, is offered the ability to browse the Internet 

performed when a user logs in via a secure token device. and to send emails, visit chat rooms and visit news sites. The 

FIG. 10 is a flow chart illustrating the steps that are second user may be charged additional amounts for the 

performed when a user desires to access services provided 50 expanded service. Other types of expanded service may 

by an ISP. include secure email and authenticated connections with 

FIG. 11 is a flow chart illustrating the steps that are other users, 

performed when an ISP seeks context information from a FIG. 1 is a block diagram that illustrates several of the 

user. hardware components employed in the illustrative embodi- 

FIG. 12 illustrates the logical organization of a user 55 ment consistent with the present invention. These compo- 

profile. ncnts include a secure token device 10 that is provided for 

FIG. 13 is a flow chart ilhistrating the steps that are a user. The secure token device 10 may be any sccurc device 

performed to restore a context in the illustrative embodiment that is capable of holding electronic currency tokens, idcn- 

of the present invention. tification information and context information. Preferably, 

FIG. 14 is a flow chart iUustrating the steps that are ^ the secure token device is of an appropriate size, weight and 

performed in billing a customer for services rendered by an shape to be portable and easily carried by a user. Suitable 

]3P secure token devices include smart cards and ibuttons. A 

secure token device is an integrated circuit card that pref- 

DETAILED DESCRIPTION OF THE e^jbiy ^ ^^^^ ^ gi i^to a user's wallet or purse. Ideally, a 

INVENTION 55 sman q^^^ size of a credit card. The smart card has 

In the illustrative embodiment consistent with the present computer components such as a microprocessor and a stor- 

invention. a user gains access to services provided by an ISP age embedded in it. A smart card that may be used to practice 
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the present invention may comply with the ISO-7816 stan- 
dard or the EMV integrated circuit card specification. For 
purposes of the discussion below, it is assumed that if a 
smart card is used as the secure token device, the smart card 
complies with the JavaCard 2.1 specification as defined by 5 
Sun Microsystems, Inc. The JavaCard 2.1 specification 
requires that the secure token device be capable of running 
programs written in the Java™ programming language. Java 
is a trademark of Sun Microsystems, Inc. Those skilled in 
the art will appreciate that the programs used to practice the 
present invention may be wrinen in programming language 
other than Java™, including C, C+-i- and Basic. 

An ibutton is a computer chip that is boused in a cylin- 
drical housing (such as a steel canister). The housing is 
designed to withstand the harsh conditions of outdoor envi- 
ronments. The ibutton may be iocorporated into a ring or 
other wearable item. For instance, ibuttons may be affixed to 
badges, watches, rings key chains and the like. The chip 
within the housing includes a microprocessor and may also 
contain computer memory, a clock or sensors. Such ibuttons 
are used by contacting tbe ibuttons with readers (e.g. "blue 
dot receptors") that are cabled into the serial ports of 
associated computers. A suitable ibutton for practicing the 
illustrative embodiment consistent with the present inven- 
tion is the Java™ Ring produced by Dallas Semiconductor 25 
Corporation. 

The hardware components used in the illustrative embodi- 
ment consistent with the present invention also include a 
reader 12. Tbe reader 12 is a device for facilitating com- 
munications between a computer system 14 and the secure 30 
token device 10. The reader 12 provides a path for applica- 
tion programs run on computer system 14 to communicate 
with the secure token device 10. Preferably, when the seciu^ 
token device is a smart card, the reader 12 is compliant with 
the OpenCard standard. The OpenCard standard is a stan- 35 
dard that provides for inter-operability of secure token 
device applications across devices, such as network 
computers, laptop computers, desktop boxes, desktop 
computers, cellular phones and personal digital assistants 
(PDAs). A number of different commercially available card 40 
terminals may be utilized as the reader 12 when the secure 
token device is a smart card. A suitable reader is the EBM 
594A card terminal. When the secure token device 10 is an 
ibutton, a suitable reader is the DS1402 blue dot receptor 
from Dallas Semiconductor Corporation. The reader may 45 
also be a proximity detector. 

The computer system 14 may be a PDA, a personal 
computer (PC) or a workstation. The configuration of the 
computer system 14 will be described in more detail below. 
The computer system 14 may communicate with a remote 50 
server computer system 16 via a communications link 15. 
The communications link 15 may be, for example, a tele- 
phone line connection. More generally, the communication 
link 15 may be a wireless connection, a cable modem 
connection, a satellite connection or a direct connection. The 55 
remote server 16 is controlled by the ISP and provides the 
user with access to the Internet. 

FIGS. 2A and 2B illustrate an exemplary physical layout 
for a smart card to be used as the secure token device 10. The 
secure token device 10 is formed on a plastic substrate 20. 60 
The front of the card (as shown in FIG. 2A) includes a 
number of electrical contacts 16 which facilitate communi- 
cations with the smart card. FIG. 2C shows these contacts 16 
in more detail. Contact 24 is used to connect with the power 
source that is provided by the smart card reader. Contaa 26 6S 
is to be coupled to a ground connection on the smart card 
reader. Contact 28 is used for input/output of data packets 
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(described below). Contact 30 is used to reset the smart card, 
and contact 32 is used for a check procedure performed on 
the smart card to ensure that the smart card is operating 
properly. Optional contacts 34, 36 and 38 are also provided. 
The front of the smart card may also include an embossing 
area 18 where the user may sign the smart card. The back of 
the smart card (as shown in FIG. 2B) may include a 
magnetic strip 22 for holding information that is magneti- 
cally encoded. In some applications, the smart card may be 
used as an ID badge that permits a user access to certain 
locales. The magnetic strip may hold information that per- 
mits the user to gain access to a secure area or other locales, 
for example. 

Those skilled in tbe ait will appreciate that the physical 
layout of the smart card shown in FIGS. 2A-2C is intended 
to be merely illustrative and not limiting of the present 
invention. The secure token device used to practice the 
present invention may have a different physical configura- 
tion with additional components or fewer components than 
shown in FIGS. 2A-2C. 

FIG. 3 depicts an example of the physical layout of a Java 
Ring 35 that is suitable for practicing the present invention. 
Tbe Java™ Ring 35 includes a steel cylindrical housing 37 
that houses an integrated circuit (IC) 41 that contains a 
microprocessor and a sUDrage (i.e. a computer memory). The 
Java™ Ring 35 also includes a ring portion 39 that enable 
a user to wear the whole device like an ordinary ring. As will 
be described in more detail below, the processor and storage 
work in conjunction to runs programs that help facilitate the 
illustrative embodiment of the present invention. 

HG. 4 shows a block diagram of tbe computer architec- 
ture of tbe secure token device 10. Tbe computer architec- 
ture includes a microprocessor 40 and a storage 42. The 
storage 42 may be formed by different types of devices, 
including random access memory (RAM), read only 
memory (ROM), and electrically erasable programmable 
read only memory (EEPROM) devices. Those skilled in the 
art will appreciate that the storage 42 may also include other 
types of storage devices. The storage 42 holds a number of 
types of data and programs that may execute on the micro- 
processor 40. In the illustrative embodiment of the present 
invention, it is assumed that the processor 40 on the secure 
token device 10 is capable of ruiming programs wriuen in 
the Java™ programming language. An "applet" is a special 
type of program that runs inside an applet viewer, a web 
browser or a secure token device. Tbe storage 42 holds a 
copy of an ISP applet 44. The ISP applet 44 enables the 
seciu'e token device 10 to communicate with an ISP and to 
receive services from an ISP. Those skilled in tbe art will 
appreciate that (he secure token device may instead run 
programs in programming languages other than Java™. 

Tbe storage 42 also hokis a copy of a banking applet 46 
that allows the secure token device 10 to be utilized in 
electronic commerce transactions. As will be described in 
more detail below, in the illustrative embodiment, the bank- 
ing applet 46 allows the secure token device to be used with 
a MONDEX system or other type of electronic commerce 
system. The secure token device 10 may hold tokens rep- 
resenting units of electronic currency that may be used to 
pay for goods and services. The banking applet provides the 
intelligence for participating in such transactions. The stor- 
age 42 may also hold other af^lets 41. 

The storage 42 holds a copy of a user profile 48. The user 
profile contains personal information regarding a user. 
Preferably, as will be described in more detail below, the 
user profile 48 complies with the Open Profiling Standard 
(OPS) and/or the Information & Content Exchange (ICE) 
protocol. 
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The storage 42 additionally holds the JavaCard API as into packages. The JavaCard API 50 is divided into a number 
defined in the JavaCard 2.1 specification. In instances where of packages 78, as shown in FIG. 6. The java.lang package 
the secure token device is not a snaart card, other similar API 80 conuins a number of object classes that arc concerned 
sets may be alternatively used. The JavaCard API is an with exceptions, such as run time exceptions and security 
application program iateiface that provides a broad range of 5 exceptions. The javacard.framework package S2 contains 
functionality for the secure token device 10. The major object classes for APDUs (defined below), applets, PINs and 
components of the JavaCard API 50 will be described in various system constants. The javacardx. framework pack- 
more detail below. The applets stored on the secure token age 84 contains object classes relating to file system struc- 
devioe 10 may instantiate object classes defined in the API tures. The jacacardx.crypto package 86 holds objects that 
to realize desired fiinctionali^. The storage 42 holds a copy provide cryptography support on the secure token device 10. 
of a JavaCard virtual machine (VM) 52. The JavaCard The javacardx.cryptoEnc package 88 contains object classes 
virtual machine is like a conventional Java virtual machine relating to the DBS encryption scheme. These packages are 
but is streamhncd to operate with the memory and process- described in more detail in JavaCard 2.1 Application Pro- 
ing restrictions that are found with secure token device 10. gramming Interfaces, specification from Sun Microsystems, 
The JavaCard VM provides platform independence for the Inc., which is explicidy incorporated by reference herein. 
Java programs that are mn on the processor 40. Programmatic support for use of the secure token device 

Those skiUed in the art wiU appreciate that the secure provided on the computer system 14. The OpenCard 

token device 10 may hold additional programs and data that provides a number of interfaces that facilitate 

differ from that shown in RG. 4. communications with the secure token device. FIG. 7 A 

«. • .,1 . J- .1. . u V r depicts the major components of the OpenCard API 76. The 

FIG. 5 IS a block diagram that shows the components of CardTerminal component 90 abstracts the readers (also 

the computer system 14 m more detail. Computer system 14 ^no^ ^ terminals) that help to interface the secure 

mcludes a central processor unit (CPU) 54 for execuUng token device 10 with the computer system 14. Each reader 

mstructions. A number of peripheral devices, mcluding a (see FIG. 7B) is represented by an instance of the CardTer- 

keyboard 56, a video display 58, and a mouse 60, may be minal object class 85. A CardTerminal Factory 83 object 

provided as part of the computer system 14. A modem 62 25 class is defined to instantiate instances of the CardTerminal 

may be provided to allow the computer system to oommu- object class. The CarcTTerminalRegistry object class 81 

nicate over analog telephone lines, and a network adapter 64 (FIG. 7B) is defined as part of the CardTerminal component 

may be provided to facilitate the connection of the computer 90. Only a single instance of this object class exists and this 

system 14 to a local area network (LAN)- As has been instance serves as the system-wide registry. Register© and 

discussed above, the computer system 14 may also include 30 unregisterQ methods are provided for this object class to 

other components, such as a cable modem, for facilitating dynamically add or remove card terminals from the registry, 

remote communications with the remote server 16. A slot object class is defined for each slot in a reader. Each 

The computer system 14 includes both primary storage 68 instance 87A and 87B of this object class represents a 

and secondary storage 66. The secondary storage 66 may physical card slot in a card terminal. A CardID object class 

include a number of types of persistent storage. For 35 89 is defined in the CanJTerminal component 90 to represent 

example, the secondary storage 66 may include CD-ROM a secure token device. 

drives, hard disk drives and other types of computer- The CardAgent component 92 abstracts an agent that 
readable mediums. The primary storage 68, likewise, may operates on behalf of the secure token device 10. A Card- 
include a number of different types of storage, including Agent object class 91 (See FIG. 7C) is defined in this 
DRAM, SRAM, and the like. The primary storage 68 holds 40 package to abstract the functionality of the secure token 
a copy of an operating system 70. The Solaris® operating device. Each agent has a separate instance of the object 
system is suitable for practicing the illustrative embodiment class. Communications between the secure token device 10 
of the present invention. "Solaris" is a registered trademark and the computer system 14 pass through the CardAgent. A 
of Sim Microsystems, Inc. A web browser 72 is provided in CardAgent Factory object class 93 support instantiation of 
primary storage 68 to facilitate access to the Internet. 45 CardAgent objects 91 and a CardAgent Factory Registry 
Suitable web browsers include Netscape Navigator, object class 95 may be instantiated to hold a registry of all 
Netscape Communicator and Microsoft Intemet Explorer. It agents. 

should be appreciated the web browser 72 may include The CardlO component 94 contains object classes that are 

intelligence for processing hypertext mark-up language used to support input/output relative to the secure token 

(HTML) documents. A Java''" VM 74 is provided in primary 50 device 10. All application interaction with the secure token 

storage 68 for interpreting Java programs. The OpenCard device 10 takes place through objects of the object classes 

API 76 is also found within the primary storage 68. Addi- defined in this component 94. A SmartCard objea class 97 

tional applications 78. including Java applets, may also be (See FIG. 7D) is defined to represent a physical secure token 

stored in the primary storage 68. These applications may device. Access to the file system on the secure token device 

instantiate objects of the object classes defined in the Open- 55 10 is achieved by mounting a root master file, resulting in an 

Card API to realize needed functionality. instance of the CardFile object class 99 A, which is defined 

Those skilled in the art will appreciate that various ones as part of the CardlO component 94. An application can 

of the components depicted in FIG. 5 as being stored in the access other files on the secure token device 10 by instan- 

primary storage 68 may alternatively be stored in the sec- tiating appropriate CardFile objects 99B and 99C. FIG. 7D 

ondary storage 66. Those skilled in the art will also appre- 50 show an example where three card file objects are instanti- 

ciate that the computer system 14 shown in FIG. 5 is ated. The CardRandomAccessFile object class 103 defines 

intended to be merely illustrative and not limiting of the objects that allow programs to access contents of the asso- 

present invention. Further, it should be appreciated that the ciated files. 

reader 12 shown in FIG. 1 may be integrated as part of the The OpenCard Framework and API are described in more 

computer system 14. 65 detail in "Secure token devices and the OpenCard 

The Java*^" programming language is object-oriented. It Framework, 'lavaWorld, January 1998, which is expHcitly 

generally supports the arrangement of sets of object classes incorporated by reference hcrcia 
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The secure token device 10 and the computer system 14 value for the user within its storage 42 (FIG. 4). The PIN 

communicate by passing data packages back and forth. value may be stored as part of the user profile 48. The 

These data packages are known as application protocol data JavaCard API 50 defines a PIN object class for holding a 

units (APDUs). The format for APDUs is defined in the PIN value, and this object class includes methods for access- 

ISO-7816 standard. Each APDU conUins cither a command 5 pi^ These methods are used to obtain the proper 

or a response to a command. A master-slave model may be pjj^ p,^ ^^j, ^^^^^^ ^ 

followed where the secure token device 10 plays the slave „^ . * .u htkt u i . •u . „ 

, . 1 .t. / 1 user. The use of the PIN helps to ensure that the proper party 

role and the computer system 14 plays the master role. The ^ l.. , . 

secure token device 10 always waits for a command APDU unauthorized party is utilizmg the secure token 
from the computer system 14 by way of the reader 12. The lO device. If the correct PIN has been entered (see step 140 m 

secure token device 10 then executes the command specified FIG- granted access to the computer system 14 

in the command APDU and replies to the terminal with a (step 142 in FIG. 9). If the correct PIN is not entered, the 

response APDU. Aclient/server model may also be followed user may be given an additional opportunity to enter the 

wherein the computer system 14 serves as a security server proper PIN. The information stored on the secure token 
and the secure token device 10 serves as a client. IS device identifies the maximum number of tries that may be 

FIG. 8 A depicts the logical format of a command APDU attempted bcU^^c user is denied access. Hence, in step 144 of 

ICO. The mandatory header 102 encodes the command that f[g. 9, a determination is made whether the maximum 

is to be encapsulated in the APDU. The header 102 includes number of tries has been reached or not If the maximum 

four fields: the OA field 106, the INS field 108, the PI field ^^^^^ ^^es has been reached, the user is denied access 

110 and tlx P2 field 112. THe CLA field 106 is a dass byte 20 ^ ^^^^^ ^ ^ 

that identifies an obicct class, such as an apphcation pro- : ^ . . . f . l . • 

gram. The INS field 108 is an instruction byte that identifies bcgmmng with step 134 m FIG. 9 where the user is 

the instruction (i.e. the command). The PI field 110 and the prompted to enter a PIN. 

P2 field 112 are parameter bytes that provide further quali- After login, the user may desire to access services pro- 
fication of the APDU command These fields 110 and 112 are 25 vided by the ISP (step 148 in HG. 10). For example, the user 

used to pass parameters with the command. may double click on an icon associated with the ISP or the 

The command APDU 100 also contains a conditional body system may automatically attempt to grant the user access to 

104. The conditional body 104 contains three fields: the Lc the ISP services once login is completed. A two-way chal- 

field 114, the data field 116, and the Le field 118. The Lc field lenge response authentication is then initiated. First, the ISP 

114 holds a value that identifies the number of bytes in the ^ remote server 16) issues a challenge to the secure token 

data field 116. Tlie data field 116 is used to hold data, and the ^^^^ ^^^^ ^^^^^ ^ ^^^^^^ 

Le field 118 identifies a maximum number of bytes that are . .en /* • <av .i 

J • .1. J . n ij • .1- AnT^ii .i. . • . 1. the ISP services (step 150 m FIG. 10). The secure token 

expected m tbe datafield m the response APDU that IS to be ^ . . . « . , , 

received after the command APDU 100 is processed. ^^^^^ chaUenge and responds (step 152 m 

FIG. 8B shows logical fonnat of a response APDU 101. ^^}' ^"^P^^ .^^^^^ ' f't 

The response APDU may contain a conditional body 120 ^"^^ ^° encryption key). The ISP applet 44 

and a mandatory trailer 122. The conditional body 120 contams the appropriate mteUigence for responding to such 

includes a data field 124 for holding data. The mandatory a challenge. The challenge may be issued by one of the 
trailer 122 conUins an SWl field 126 and an SW2 field 128. ^ applications 78 stored in the primary storage 68 of the 

These two fields each bold a respeaive stams byte that computer system 14. If the response is not proper (step 154 

reflectsthestamsof the command for which the response is in FIG. 10), the services provided by the ISP are not 

sc°t. accessed (step 164 in FIG. 10). If the response, however, is 

FIG. 9 is a flow chart that illustrates the steps that are proper, the user is authenticated, and a challenge is issued by 
performed during initial login when a user using secure 45 the secure token device 10 to the ISP (step 156 in FIG. 10). 

token device 10 attempts to gain access to computer system The ISP responds to the challenge by submitting a response 

14. The role played by the secure token device 10 during (step 158 in FIG. 10). If the response is proper (see step 160 

login may be encoded in one of the applets 41 stored in the in FIG. 10). the services provided by the ISP are accessed 

storage. Initially, the user places the secure token device 10 (step 162 in FIG. 10). In contrast, if the response is not 

in position for reading by reader 12 (step 130 in FIG. 9). The proper, the services are not accessed (step 164 in FIG. 10). 

reader 12 detects the presence of the secure token device 10 Those skilled in the art that multiple two way auihentica- 

and then informs tbe computer system 14 (step 132 in FIG. tions may be performed. 

9). A number of differem login options may be foUowed but, n should be appreciated that each user has a globally 
in general, the computer system 14 begins the login process 55 unique ID that is encoded on the secure token device. The 
by sending appropriate command APDUs via tbe reader 12 user ID is unique across geographic and political bound- 
to the secure token device 10. The commands prompt the aries. This user ID may be used in formulating the challenge 
user to enter a PIN value (step 134 in FIG. 9). The PIN may that is issued by the ISF Eadi ISP also has a globally unique 
be, for example, a code constituting between 4 to 8 digits ^D. The ISP ID may be used in the challenge-response 
that is uniquely assigned to the user. The reader 12 may protocol. 

include a keypad that is used to enter the PIN or, Those skiUed in the art wiU appreciate that a number of 

alternatively, the user may enter the PIN via the keyboard 56 chaUenge/response protocols may be utilized m 

.I.*- ^ c.i. . . i>i/* i^z: • rii- n\ performing this two-way authentication. For example, SHA- 

that is part of the computer system 14 (step 136 in FIG. 9). ^ ^^^^ ^^^^^ ^ Moreover, those 

The PIN entered by the user is then compared with the 55 skilled in the art wiU appreciate that the ISP may be first 

PIN value assigned to the user (step 138 in FIG. 9). In presented with tbe challenge rather than the secure token 

particular, the secure token device 10 holds the proper PIN device. 



12/18/2002, EAST Version: 1.03.0007 



us 6,385,729 Bl 



11 



12 



Befwe the ISP begins providing services or sometime 
dining session where the ISP is providing services, the ISP 
may seek personal information from the user profile 48 
stored on the secure token device 10. The format of the user 
profile 4Q will be described in more detail below. The ISP 5 
begins the process by requesting information from the 
profile 48 (step 166 in FIG. U). Pennissions are defined for 
each requester that may request personal information of the 
secure token device 10. These permissions identify what 
portion or subset of profile data may be accessed by the 
requester. In response to the request from the ISP, the secure 
token device 10 accesses the permissions that are provided 
for the ISP (^ep 168 in FIG. 11). The request identifies what 
information is sought from the secure token device. The 
sccuic token device determines whether the ISP has the 
permissions needed to receive the requested information 
(step 170 in FIGS. 11). If the ISP lacks the appropriate 
permissions, the ISP is denied access (step 172 in FIG. 11). 
If the ISP has the appropriate permissions, the ISP is granted 
access to the information, and the secure token device 10 
forwards the information to the ISP (step 174 in FIG. 11). 20 
This information may be forwarded from the secure token 
device 10 to the computer system 14 in encrypted form for 
security purposes. It should be appreciated that the secure 
token device may partially grant the request where an ISP 
requests information that it is permitted to receive as well as 25 
information it is not permitted to receive. 

FIG. 12 shows a logical organization of an illustrative 
user profile 178. In the illustrative embodiment consistent 
with the present invention, the user profile may conform 
with the Open Profiling Standard (OPS). In accordance with 30 
that standard, the infonnation contained in the user profile is 
divided into sections and subsections. In the exemplary case 
shown in FIG. 12, the profile 178 is divided into a first 
section 180 and a second section 182. Suppose that the first 
section 130 contains address information and section 182 35 
contaiiE credit card information. The first section 180 also 
contains a subsection 188. This subsection 188 may contain, 
for example, a phone number. Each statement is a name/ 
value pair The first section includes statements 184 and 186 
that assign given values to properties. The subsection 188 40 
also contains a statement 190 that assigns a data value to a 
property. Permissions arc granted on a section or subsection 
basis. 

The information contained in the user profile 48 may vary. 
The user profile may contain information such as name, 45 
address, and credit card information. In general, the infor- 
mation is personal to the user. 

As was discussed above, the secure token device 10 may 
be used as a vehicle for preserving contextual infonnation. 
In particular, the context of a given session with an ISP may 50 
be preserved for later restoration in a subsequent session. 
The context may hold a wide variety of different informa- 
tion. For instance, user preferences regarding settings and 
various web sites may be restored in the context Where the 
ISP begins a session with the user, the ISP requests contex- S5 
tual information from the secure token device 10 (step 192 
in FIG. 13). The secure token device then provides the 
context to computer system 14, which forwards the infor- 
mation to the ISP at the remote server 16 (step 194 in FIG. 
13). The contextual information is used to restore the 60 
previous context (step 196 in FIG. 13). Subsequently, the 
ISP seeks to store the new context of the current session with 
the secure token device 10 so that the new context may be 
subsequently restored in the next session (step 198 in FIG. 
13). The new context is sent to the secure token device 10 65 
and the secure token device stores the new context for 
subsequent use (step 200 in FIG. 13). 



The secure token device 10 may provide the ability for the 
user to pay for services rendered by the ISP during a session 
with the ISP. As was discussed above, this also assists the 
ISP in tailoring services to a particular user and in charging 
the user based upon resource utilization. Initially, the user 
seeks an ISP service, such as web browsing or electronic 
mail (step 202 in FIG. 14). The ISP then levies a charge for 
user to access the servers (step 204 in FIG. 14). The secure 
token device returns an electronic token representing 
amount of currency to the ISP (step 206 in FIG. 14). As was 
mentioned above, the secure token device 10 includes a 
banking applet 46 that supports the ability to respond to 
requests and to deliver tokens. The banking applet 46 may 
support transactions involving MONDEX tokens or other 
types of electronic currency tokens. MONDEX is an elec- 
tronic transaction system that employs smart cards for 
person-to-person payments. MONDEX was developed by 
National Westminster Bank in conjunction with Midland 
Bank and British Telecom and has been in use since July 
1995. MONDEX uses tokens of a specified format. 

The ISP receives the tokens and deposits the tokens in an 
appropriate account (step 208 in FIG. 14), After receiving 
payment, the ISP then grants the user access to the server 
(step 210 in FIG. 14). The Java electronic commerce frame- 
work (defined by Sun Microsystems, Inc.) is an open plat- 
form for development of electronic commerce applicators in 
Java. This framework may be used by the banking applet 46. 

Those skilled in the art will appreciate that a number of 
different electronic transaction systems may be utilized in 
the present invention. The present invention is not limited to 
using MONDEX currency. Moreover, the billing scheme 
may differ from that shown in FIG. 14. The timing at which 
a party is charged for services may differ such that a party 
is charged after having finished using a service rather than 
before accessing the service. Furthermore, there may be 
instances where an ISP is required to provide change in the 
form of tokens that are returned to the secure token device 
10. 

While the present invention has been described with 
reference to an iUusU^ative embodiment thereof, those skilled 
in the art will appreciate the various changes in form aiKl 
detail may be made without departing from the intended 
scope of the present invention as defined in the appended 
claims. For example, different varieties of secure token 
devices may be used to practice the present invention. 

What is claimed is: 

1. In a computer system where a user accesses services 
provided by a service provider during sessions via a con- 
nectionless protocol, a method comprisiiig the steps of: 

providing a secure token device for a user, said secure 
token device holding contextual information that cap- 
tures a context of a last session the user had with the 
service provider; 

on behalf of the service provider, receiving the contextual 
information from the secure token device; and 

using the contextual information to restore the context of 
the last session the user had with the service provider 
during a current session where services are provided by 
the service provider to the user. 

2. The method of claim 1 wherein the connectionless 
protocol is the Internet Protocol (IP). 

3. The method of claim 1 wherein the service provider is 
an Internet Service Provider (ISP) that provides the user 
with access to the Internet. 

4. The method of claim 1 wherein the contextual infor- 
matbn identifies a uniform resource Location. 
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5. The method of claim 1 whereiD the secure token device 
is a smart card. 

6. The method of claim 1 wherein the secure token device 
is an ibutton. 

7. The computer system of claim 1 wherein the connec- 
tionless protocol is the Internet Protocol (IP). 

8. In a secure token device, for vsc by a user in accessing 
services of a service provider via a connectionless protocol 
during sessions, a method comprising the steps of: 

providing contextual information that captures a context 
of a last session that the user bad with the service 
provider on the secure token device; 

receiving a request to read the contextual information on 
"behalf of the service provider; and 

in response to the requests, outputting the contextual 
information for use by the service provider in restoring 
the context of the last session in a current session where 
services are provided by the service provider to the 
user. 

9. The method of claim 8 wherein the connectionless 
protocol is the Internet Protocol (IP). 

10. The method of claim 8 wherein the service provider is 
an Internet Service Provkier (ISP) that provides the user 
with access to the Internet. 

11. The method of claim 9 wherein the service provider is 
an Internet Service Provider (ISP). 

12. The method of claim 8 wherein the contextual infor- 
mation identifies a web site. 

13. The method of claim 8 wherein the secure token 
device is a smart card. 

14. The method of claim 8 wherein the secure token 
device is an ibutton. 

15. In a secure token device that interfaces with a com- 
puter system, wherein a user accesses services provided by 
a service provider on the computer system, a method com- 
prising the steps ot 

providing personal infiDimation about the user in the 

storage of the secure token device; 
establishing what poition of the personal information is 

permitted to be given to the service provider upon 

request; 

receiving a request from the service provider at the secure 
token device to obtain at least some of the personal 
information about the user, and 

in response to the request, sending to the service provider 
only information from the portion of the personal 
information that is permitted to be sent to the service 
provider. 

16. The method of claim 15 wherein the information that 
is sent to the provider includes less than all of the informa- 
tion requested. 

17. The method of claim 15 wherein the user establishes 
the portion of the personal information that is permitted to 
be given to the service provider upon request. 

18. The method of claim 15 wherein when the service 
provider requests only information that is not permitted to be 
given to the service provider, the request is rejected by the 
secure token device. 

19. The method of daim 15 wherein the secure token 
device is a smart card 

20. The method of daim 15 wherein the secure token 
device is an ibutton. 

21. In a secure token device that interfaces with a com- 
puter system, wherein a user of the secure token device 
receives services from an Internet service provider (ISP) on 
the computer system, a method comprising the steps of: 
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providing tokens representing currency on the secure 
token device; 

, receiving a request for payment for services from the ISP; 
and 

forwarding at least one token from the secure token 
device to the ISP in response to the request. 

22. In a network having a computer system where a user 
accesses services provided by a service provider during 
sessions via a connectionless protocol and a secure token 
device for enabling the user to access the services provided 
by the service provider, wherein the secure token device 
holds contextual information that captures a context of a last 
session the user bad with the service provider, a computer- 
readable medium holding computer-executable instructions 
for performing a method, comprising the steps of: 

receiving the contextual information from the secure 
token device on behalf of the service provider, 

using the contextual information to restore the context of 
the last session the user bad with the service provider 
during a current session where services are provided by 
the service provider to the user. 

23. The computer-readable medium of claim 22 wherein 
connectionless protocol is the Internet Protocol (IP). 

24. The computer-readable medium of claim 22 wherein 
the service provider is an Internet Service Provider (ISP) 
that provides the user with access to the Internet. 

25. The computer-readable medium of claim 22 wherein 
the contextual information identifies a web site. 

26. In a system where a secure token device that interfaces 
with a computer system, wherein a user accesses services 
provided by a service provider on the cotnputer system and 
personal information about the user is provided in the 
storage of the secure token device, a computer-readable 
medium holding computer-executable instructions for per- 
forming a method comprising the steps of: 

establishing what portion of the personal information is 
permitted to be given to the service provider upon 
request; 

receiving a request from the service provider at the secure 
token device to obtain at least some of the personal 
information about the user, and 

in response to the request, sending to the service provider 
only information from the portion of the personal 
information that is permitted to be sent to the service 
provider. 

27. The computer-readable medium of claim 26 wherein 
the information that is sent to the provider includes less than 
all of the information requested. 

28. The computer-readable medium of claim 26 wherein 
when the service provider requests only information that is 
not permitted to be given to the service provider, the request 
is rejected by the secure token device. 

29. The computer-readable medium of claim 26 wherein 
when the service provider requests only information that is 
not permitted to be given to the service provider, the request 
is rejected by the secure token device. 

30. The computer-readable medium of claim 26 wherein 
the service provider is an Internet Service Provider (ISP). 

31. The computer-readable medium of claim 26 wherein 
the secure token device is a smart card. 

32. The computer-readable medium of claim 26 wherein 
the secure token device is an ibutton. 

33. A computer system wherein a user accesses services 
provided by a service provider during a during sessions via 
a connectionless protocol and a secure token device is 
provided for the user, said secure tokcQ device holding 
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coatextual informatioa that captures a context of a last 
session that user had with the service provider, said com- 
puter system comprising: 

interface means for interfacing with the sec\ire token 
device to facilitate communications between the com- ^ 
puter system and the secure token device; 
means for receiving the contextual information from the 
secure token device; and 
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means for using the contextual information to restore the 
context of the last session the user had with the service 
provider during a current session where services are 
provided by the service provider to the user. 
34. The computer system of claim 33 wherein the secure 
token device is a smart card. 

* * « * « 
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